Better change tracking for Semantic highlighting for CSL#8099
Better change tracking for Semantic highlighting for CSL#8099lkishalmi merged 1 commit intoapache:masterfrom
Conversation
|
hmm. I like the simplifications. Although |
73af1c8 to
419b0a4
Compare
|
At the end removed |
b9a60d7 to
7c133c3
Compare
|
Before this is progressed further a regression needs to be fixed first. See #8102 |
7c133c3 to
4cc8d6f
Compare
|
Rebased the code from master with @matthiasblaesing fix, added one more unit test to check the skipping of empty highlights. |
4cc8d6f to
2c140c7
Compare
matthiasblaesing
left a comment
There was a problem hiding this comment.
I saw nothing obviously wrong here.
Instead of tracking changes in a series of
Editrecords between parsing there could be DocumentPositionused, which automatically track the offset changes in the edited document.This version further simplifies the highlighter.
Also resolves a minor issue, that would not extend the previous highlight when the new text is just appended after a whole token.
Before:
Screencast From 2024-12-29 15-53-25.webm
After:
Screencast From 2024-12-29 15-50-57.webm
This may have better performance as well. There was some minor flickering on highlights when the edit list grew "large" (basically that needed a lot of monkey style keyboard clamping, to be noticeable)
I have a minor aversion to put Position which is a mutable thing info the
SequenceElementrecord, though it is used to grouping data together, also changes in the document, shall not change the order of the instances when put in a collection, so I could live with that. Please tell me if you have something better in mind.